For many years now, telecommunications carriers have been deploying packet-switched networks in place of, or overlaid upon, circuit-switched networks for reasons of efficiency and economy. Packet-switched networks, such as Internet Protocol (IP) or Ethernet networks, are intrinsically connectionless in nature and, as a result, suffer from Quality of Service (QoS) problems. Customers value services which are guaranteed in terms of bandwidth and QoS.
Carriers may use Multi-Protocol Label Switching (MPLS) over a layer 2 network to create connection-oriented label switched paths (or tunnels) across the intrinsically connectionless network and, thereby, provide guaranteed QoS and bandwidth services to customers. However, MPLS is a relatively unstable and complex standard and carriers may desire an alternative.
It is desired to use Ethernet switches in carriers' networks. Use of Ethernet switches in carriers' networks is expected to have advantages including interoperability (mappings between Ethernet and other frame/packet/cell data structures such as IP, Frame Relay and Asynchronous Transfer Mode are well known) and economy (Ethernet switches are relatively inexpensive when, for example, compared to IP routers). The use of Ethernet switches in carriers' networks is also expected to provide a distinct advantage in that Ethernet is the principal technology used by enterprises that require wide area network service from a carrier.
However, the behavior of conventional switched Ethernet networks is incompatible with carriers' requirements for providing guaranteed services to customers. Carriers require a network to be meshed for load balancing and resiliency, i.e., there must be multiple paths across the carrier network, and require a network to include an ability to perform traffic engineering, i.e., the ability of a network operator to control the provision of explicitly-routed, variable bandwidth connections (or tunnels) through which traffic may be directed. Such a required network is expected to provide operators significant flexibility in that the physical network build is not obliged to correspond to the offered load and, therefore, the physical network build is tolerant of changing usage patterns without requiring on-going physical modifications.
In contrast, conventional Ethernet networks must be simply-connected, i.e., there must be one, and only one, logical path choice between each and every node of the network. As a consequence, conventional Ethernet networks do not have support for network-wide load balancing, suffer from resiliency problems and cannot support traffic engineering. Further, the impact of a single failure, with respect to the overall load carried, can be significant.
Spanning tree protocols are known. Such spanning tree protocols enable a physically meshed Ethernet network to be logically transformed into a simply-connected network by detecting physical loops and logically disabling connections to break up any loops that may arise. Certain spanning tree protocols are known to detect failure of a physical connection (thereby partitioning the fully-connected network) and automatically restore one or more previously-disabled physical connections so as to re-connect the network. This provides a degree of resiliency. However, carriers need to plan their network traffic routes to achieve much higher resiliency, flexibility and efficiency than known spanning tree protocols can achieve. This level of routing capability is best achieved by segregating the traffic into connections whose routes are determined as part of this planning process.
Recently, the Institute of Electrical and Electronics Engineers (IEEE) has introduced a user priority indication capability that enables the definition of up to eight service classes, also known as Classes of Service (CoS), which allows some segregation of traffic. A set of Ethernet frames that have the same user priority indication may receive the same level of performance within the service provider's network, where level of performance is often measured in terms of frame loss ratio, frame delay and frame delay variation.
A standard, known as IEEE 802.1Q, defines an architecture for a general purpose Virtual Local Area Network (VLAN) that may be implemented within an enterprise network as a point-to-point connection, a point-to-multipoint connection or a multipoint-to-multipoint connection. IEEE 802.1Q describes a four-byte extension to Ethernet frame headers, where the four-byte extension is known as an IEEE 802.1Q tag. This tag includes a number of fields, including a 12-bit VLAN-ID field (VLAN tag field) and a three-bit “user priority” field used to signal compliant devices. These three bits (normally referred to as the “p-bits”) provide for eight possible values, which match those used in the known IEEE 802.1p user priority field.
A single Ethernet VLAN has a capability to support the transmission of Ethernet frames requiring different classes of service (up to eight). This capability differentiates Ethernet VLANs from connections defined by other technologies such as Frame Relay (FR) or Asynchronous Transfer Mode (ATM).
The Internet Engineering Task Force (IETF) has published an Internet Draft document referred to as “draft-kawakami-mpls-lsp-vlan-00 dot txt” (currently available at www dot ietf dot org). The Internet Draft document describes the use of VLAN tags for label switching across Ethernet networks in a manner similar to the use of MPLS labels for label switching over MPLS networks; VLAN tags are used as labels to mark traffic at an ingress point of a label switched path (LSP) as belonging to a Layer 2 tunnel and VLAN-aware Ethernet switches in the network act as a VLAN label switched routers. Connections are formed using one or more LSPs. Intermediate nodes along a given connection may optionally swap an inbound label to a different outbound label. In this manner, the VLAN tag has meaning specific to any given local node and the ability to reuse VLAN tags solves some of the scalability issues of 802.1q.
However, one problem with the method proposed in “draft-kawakami-mpls-lsp-vlan-00 dot txt” is that only a maximum of 4094 unique VLAN tags are definable in 802.1q compliant equipment. This maximum limits the flexibility and increases the complexity of provisioning connections across the network. Another problem is that connections may not easily be re-routed once provisioned without, in general, creating transitory loops.
Another problem is that since the Frame Check Sequence (FCS) in Ethernet frames is computed over both the payload and header portions of the frame, every time a VLAN tag (i.e., a label) is swapped at the ingress or egress point of a LSP, the FCS needs to be recomputed since the VLAN tag will have changed. This requires performing a computation function over the entire Ethernet frame. Moreover, during the interval from when the original FCS is removed and the new FCS added, the frame is vulnerable to corruption without the protection of any FCS.
Yet another problem with the “label-swapping” approach proposed in “draft-kawakami-mpis-lsp-vlan-00 dot txt” is that it requires a “chain of correctness”, in that forwarding relies on each local label-forwarded link on the LSP being correct. This should be contrasted with conventional Ethernet which uses globally unique address information to perform forwarding. As the LSP labels are not globally unique per conventional Ethernet, it is possible for a forwarding fault, in performing label translation, to be concealed if a value is incorrectly mapped to another value that is in use. More importantly, from a practical perspective, “label-swapping” behavior represents a significant change from both conventional Ethernet switch functionality and current telecommunications standards.
The IP differentiated service architecture, “DiffServ” (see Blake, S., et. al., “An Architecture for Differentiated Services”, IETF Request for Comments (RFC) 2475, December 1998, which may be found at www dot ietf dot org and is hereby incorporated herein by reference), has now been accepted by the industry as a scalable solution for introducing classes of service for providing QoS guarantees in packet networks.
In a DiffServ domain, all the IP packets crossing a link and requiring the same DiffServ behavior are said to constitute a Behavior Aggregate (BA). At the ingress node of the DiffServ domain, the packets are classified and marked with a DiffServ Code Point (DSCP) which corresponds to the Behavior Aggregate of the packet. At each transit node, the DSCP is used to select a Per Hop Behavior (PHB) that determines how each packet is treated at the transit node. The DiffServ terms that describe how the packet is treated include scheduling treatment and drop precedence.
Le Faucheur. F., et al, “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services”, IETF RFC 3270, May 2002 (which may be found at www dot ietf dot org and is hereby incorporated herein by reference) describes different MPLS LSP types: EXP-Inferred-service class LSP (E-LSP); and Label-Only-Inferred-service class LSP (L-LSP). MPLS EXP bits are found in the MPLS shim header. The MPLS shim header is the header that is placed in packets that carry label information. The MPLS shim header is defined in IETF RFC 3032. The manner in which E-LSPs and L-LSPs can be used for supporting IP DiffServ classes is also described. RFC 3270 builds on earlier IETF standards concerning IP DiffServ and MPLS technology.
An E-LSP may support up to eight service classes in one Label Switched Path (LSP), determined through the mapping of the EXP bits to DiffServ PHBs. The mapping can be either configured or signaled during the LSP establishment. The L-LSP supports a single scheduling class determined by signaling the association between the LSP and the DiffServ scheduling class, and up to three drop precedence (DP) determined by a fixed mapping of the EXP bits to DP. Both the E-LSP and L-LSP may be established using either a connectionless protocol (such as LDP), or a connection-oriented protocol (such as RSVP-TE). In the latter case, bandwidth reservation and admission control can be optionally specified per LSP for stronger QoS guarantees. The combination of MPLS and DiffServ methods yields many benefits, including reuse of the DiffServ methods/standards and support of multiple QoS options, which are applicable to both connection-oriented and connectionless MPLS networks.
Clearly, support of DiffServ is desirable in Ethernet VLANs. It can yield the same benefits realized in MPLS networks, including differentiated traffic treatment, and support of multiple service classes with quality of service guarantees.
Recent IEEE discussions describe a table-based approach for specifying the mapping of p-bits to forwarding classes and drop precedence (see IEEE P802.1ad/D4.0, “Virtual Bridged Local Area Networks—Amendment 4: Provider Bridges”, Feb. 8, 2005). Solutions providing support of multiple QoS in Ethernet VLANs have been implemented by some switch vendors.
However, the solutions are known to be ad hoc and proprietary. The solutions either provide limited QoS support, implement simple class-based queuing, without support for drop precedence, or support a limited table-based approach for specifying the mapping of Ethernet VLANs p-bits to scheduling queues and drop precedence. Furthermore, these solutions do not provide support for Ethernet “connections” that can be assigned a specified network path, a forwarding treatment and, optionally, bandwidth reservation.